1. Field of the Invention
The present invention relates generally to the field of data processing. More specifically, the present invention relates to a system and method for providing dynamic support for multiple languages within one or more application programs.
2. Description of Related Background Art
In the early development of the software industry, engineers and developers knew the demographics of those who would use an application program. Generally, due to the cost of software and hardware, users tended to be middle to upper class business people who speak English. Additionally, the developers and designers of the application programs were of the same culture and nationality as the users of the programs. Translation and support for multiple languages was not an important issue.
Today, however, with inexpensive hardware and software being used at almost every level of society, support for multiple languages in an application program is a very important issue. The importance of multiple language support has also increased due to globalization. Businesses compete more now than ever across international borders. Often a business will have several offices around the world. As a result, the developers of an application program often speak different languages than the end users of the program.
To accommodate users of different languages, developers identify which elements of the program are sensitive to difference in language between users. Generally, these elements are the displayable elements of the program's user interface. These elements of the user interface are referred to herin as language-sensitive elements (LSEs). LSEs may include displayable elements such as symbols, numbers, text, icons, graphics, and the like. LSEs are not limited solely to words and phrases. Likewise, some icons or graphics may be understood by only a particular culture. Additionally, certain audio clips such as tones, chimes, and the like may be LSEs. The definition of which elements of an application program user interface are LSEs depends largely on who the potential user of the application program will be.
A conventional approach to providing multiple language support is to distribute an alternative set of LSEs with the application program code. Generally, this is implemented in one of two ways. First, the actual code of the program may include alternate text messages, icons, and other LSEs that are compiled and distributed with the program code. The alternate LSEs are displayed based on a global language indicator condition. For example, if the language indicator is English, then “Hello” is displayed. If the language indicator is Spanish, then “Hola” is displayed. Similar conditions may be dispersed throughout an application program. Under this technique, modifying and adding support for new languages to each LSE is very expensive because a computer programmer is needed to navigate through the code to change the LSE conditions.
A second conventional approach for supporting multiple languages is to build separate user interface code. For example, one set of code may display a set of database fields and field indicators to identify each field in a user interface window. The field indicators are generally LSEs. Therefore, a completely identical set of computer code may exist to perform all of the same functions as the first, but simply include field indicators translated into the desired languages. As a new language must be supported, the code containing LSEs is then duplicated and the field indicators are translated.
The two conventional approaches outlined are generally referred to as “hard coded” approaches and have several limitations. First, the application program code must be changed each time a new language is to be supported or an error in translation is found. Second, changes must be implemented by a computer programmer so that the application code continues to function properly. Because the changes are hard coded into the application program, the cost of fixing or modifying the program is very high. Also, duplicating the computer code increases the amount of code which must be changed if a programming bug is discovered. Additionally, each change in an LSE may require that the whole set of application program code be updated. Third, the indicator of which language the application program is to use is generally only set when the application program begins execution. Even if the language indicator may be changed, the whole program generally must be re-started to implement the change.
Application programs that support multiple languages have generally made assumptions about the user to simplify the task of providing multiple language support. For example, it is often assumed that the language used in the Operating System (OS) of a computer is the same one the user will want for application programs executing on that OS. Alternatively, it is assumed that the physical location of a particular computer is a reasonable indicator as to what language the user desires to use for all application programs on the computer.
Because these assumptions may not always be true, most OSs allow the user to modify the OS configuration settings to support a different language. However, the process generally requires that the computer system be powered down and re-booted. Re-booting generally takes from one to five minutes. Sometimes, the user does not know how, or is not allowed, to change the OS configuration settings.
While assumptions about the desired user language may have worked in the past, today's diverse workplace have made the assumptions impractical. More and more companies and organizations operate offices in various different countries. Additionally, people often live in countries whose native language differs from their own. Clear communication between the user and the application program is vital.
Conventional multiple language support by re-booting the OS or re-starting an application is impractical. For example, applications that serve as point of sale (POS) terminals, i.e. check-out stands for a retailer, are often operated by a minimum wage employee whose native language may differ from the majority of people where the store is located including the manager. Re-booting the terminal for an exchange of employees, or to allow a supervisor to momentarily operate the terminal, causes delays which most customers will not tolerate. Similarly, re-starting the application may require a sales transaction to be re-initiated as well. Configuration changes to support a different language and re-starting may lead to a significant loss of business.
Accordingly, what is needed is a system and method for providing dynamic multiple language support for application programs. What is also needed is a system and method for providing dynamic multiple language support for application programs that allows new languages to be supported without using expensive application programmer resources. Additionally, what is needed is a system and method for providing dynamic multiple language support for application programs that separates application program support and upgrades from those relating to language translations. What is also needed is a system and method for providing dynamic multiple language support for application programs that does not require re-booting the computer system or re-starting the application program to change which language is being used. What is also needed is a system and method for providing dynamic multiple language support for application programs that allows for dynamic switching of the current language of the user interface based on who the user is rather than the location of the machine or configuration of the operating system.